一次服务端性能问题排查过程

临近双11又开始另一轮的性能测试，陆续给大家奉上性能测试系列篇，从性能测试理论、性能测试案例高延迟（响应时间长）、CPU问题、内存问题、线上问题实战和性能测试书籍推荐等篇章。更多性能文章见文末链接。

陆续聊了性能测试指标和性能测试排查过程也有四五篇文章了，今天分享一个真实的性能测试真案例。

在一次某银行项目性能测试中，当系统运行到1个小时10分左右：tps出现明显下降,响应时间明显上升，其他相关业务cpu、内存、网络等各项指标都正常；此问题一直重复出现，而且在银行测试环境和公司测试环境一直存在。

通过分析怀疑可能是以下原因造成的

1.定时任务，

2.测试代码，

3.业务代码，

4.FGC。

然后就根据猜想一项一项测试验证。

1. 停掉所有定时任务，和开发确认没有段时间插入定时日志或者其他数据库操作。

2. 检查测试代码，测试代码和正确的测试代码只有很少的几行差异，而且全部是http连接规范的写法，不至于有问题。

3. 业务代码，检查所有业务日志，tomcat日志，jstack抓trace等，都未见异常。

4. Full GC 通过抓jstat信息，发现在50分左右确实出现fgc如图：

但在相同时间，该接口的TPS有少量下降， 不是原来遇到的大量下降，如图

故排除fgc问题。貌似再次测试进入死胡同，再次怀疑此应用代码问题。

就在早上突然想到是不是负载均衡工具有问题？？？？到公司迫不及待的测试下。

通过测试，去掉负载haproxy代理，自己写了一个随机分配到四个应用节点地址，通过三个小时测试，没有出现上述怪异的问题。

告诫各位，在性能测试时，特别要小心软负载工具的应用，对性能测试的影响， haproxy工具坑我好几次了，使用时一定要小心。

文章来源：MiniStarClub北京，致力于提供最具价值的测试及测试管理领域原创文章。包括测试技术、测试方法、测试思想、测试管理等。
· 推 荐 阅 读 ·RECOMMENDATION服务端性能测试指标及问题排查
服务端性能问题排查及优化---CPU高问题分析
服务端性能问题排查及优化 ---内存问题分析